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I Making Modeling Work 





Problem Statement 



Project information is stored in various documents, 
spreadsheets and systems with little consistency 
and/or formal structure 
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A lack of common understanding of a project's 
organizations, roles, objectives, behaviors and 
constraints . 
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Agenda 


□! Problem statement, objectives, agenda 
□! Theory of: 

E! Enterprise and Business Architecture 
□! Formal modeling 

□! Applying EA and Modeling to Project Management 

□! Case studies: 

□! Ares development 
□! Ames process modeling 
□iMODEAR 

□! Flight Readiness System 

□! Making Modeling Work for You Today 

□i Future Trends and Closing Remarks 
□! Q&A 




Four Modeling Perspectives 



o 

© 

© 

© 





SE Standards, Languages, AFs 



pkg [Package] Modeling Architecture [ ifgj' Enterprise Architecture Concepts ] 






Enterprise Architecture 





What is the Scope of an Enterprise 
Architecture? 


Most 

Restrictive 


Several ideas are in common use: 


!An accounting of an organization's IT artifacts and their 
application to lines of business. (Lists of IT things.) 

!The relationships and behaviors of an organization's IT artifacts 
and their application to lines of business. (Lists and Life-cycle of 
IT things.) 


!An accounting of an organization's meaningful artifacts and 
their application to lines of business. (Lists of "all" things.) 

!The relationships and behaviors of an organization's meaningful 
artifacts and their application to lines of business. (Lists and 
Life-cycle of "all" things.) 


Most 

Expansive 




FEA and DoDAF EA Definition 


□A strategic information asset base, 

□which defines the mission, 

□the information necessary to perform the mission, 

□the technologies necessary to perform the 
mission, and 

□the transitional processes for implementing new 
technologies in response to changing mission 
needs. 

□EA includes a baseline architecture, a target 
architecture, and a sequencing plan. 



How did we use an Enterprise 
Architecture? 

□iTo organize the information about our processes, 
products, people and systems 

□iTo relate these entities to one another 

□iTo provide different diagrams and reports of the 
information suitable to each of the stakeholders in 
the project 

□! To export information to other tools for analysis 
and simulations 




Benefits of Enterprise Architecture 
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«analytical» 

Simulate the 
architecture and 
produce artifacts 
used to execute 
enterprise 
processes 



^ « descriptive) 


Promote a 
common 
understanding c 


^ the enterprise 




Determine needs 
for resources, 
processes and 
data 





Zachman Framework 


Technology 
Agnostic - 
Understand 
The Business 


Technology 
Specific - 
Specify and 
Design the 
Systems to Support 
Th e Bus i n e ss 



What 

(Data) 

How 

(Function or 
Process) 

Who 

(People) 

Scope 

•List of things 
important to 
business 

•Function 

Hierarchy 

•Functions to 
Org Matrix 

List of 

Organizations 

Business 

Model 

•Conceptual 
Data Model 

•Process Model 

•Org to Function 
mapping (roles) 

System 

Model 

•Logical Data 
Model 

•Use Case 
•Activity Diagram 

•Process to Role 
Matrix 

Technology 

Model 

•Physical Data 
Model 

•Activity Diagram 

•Sequence 

Diagram 

•Roles/Access 

Matrix 

Detailed 

Design 

•Technology 

Specific 

•Technology 

Specific 

•Technology 

Specific 


ConOps 


Requirements 

System 

Requirements 

Design 

Qnor'ifir'af irtnc 




DoDAF 2.0 Framework 
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Capability Viewpoint 
Articulate the capabfllry requirement, delivery timing, 
and deployed capability 


Operational Viewpoint 

Articulate operational scenarios, processes, activities 

& requirements 


Services Viewpoint 

Articulate the performers, activities, services, and 
their exchanges providing for, or supporting, DoD 

functions 


Systems Viewpoint 

Articulate the legacy systems or independent 
systems, their composition interconnectivity, and 

context providing for, or supporting, OoD functions 


Project Viewpoint 

Describes the relationships between operational and capability 
requirements and the various projects being implemented: Details 
dependencies between capability management and the Defense 
Acquisition System process. 



Which EAF do I Use? 


■Zachman 

■lEasier to grasp and get started with. Can start with lists of "things" and 
start relating these to other parts of the business 

■Hierarchical in nature, provides good mechanism for abstracting levels of 
detail from executive to engineer 
■More IT centric 

■DoDAF 

■iMore prescriptive in nature - specific products to fill different purposes 
■Separate different viewpoints - business processes from systems that 
support them 
■Supported by many tools 

■Has a modeling language specifically designed for it: UPDM 
■General purpose 
■Create your own 

■ Ilf you don't use a standard framework - you will create your own 
mechanisms for organizing and relating information in your models! 




Use Standard Architecture 
FrameworkJVIodel or Both? 

□! Architecture Frameworks: 

□! Can range from simple (lists) to complex 

□ Useful for providing an outline of what information to gather and how to 
organize that information 

□ Can customize this outline to fit your needs 

□ Can be used to compare different systems from different vendors 

□ Can be used to study "as-is" states to "to-be" states 

□! Can leverage modeling languages such as UML, SysML, and Archimate 

□! Modeling Standards 

□ Can range from simple to complex 

□ Quick to build a few diagrams 

□! For larger projects will need to organize model 
□! Formal language/annotations used 
□! Both 

□ Provides guidance on what modeling artifacts you will need and how to 
organize them according to a standard framework 




Modeling 


Models, Formal Models and SysML 





What is a Model? 



An Abstraction of the Physical World Around Us 


• !An electrical schematic of a radio 

• !An economic model 

• !A mathematical model 

• !A model student 

• !A non working model airplane 

• !A written description of a pencil 

• !A diagram 

• !A spreadsheet 

• iMusic 

• !Art 

•iNatural languages 





Sample of Modeling Languages 


Language 


Purpose 


Language 

Purpose 

IDEFx 

Business 

UML 

Software 

BPN 

Software 

AADL 

Hardware, software, realtime (avionics, 
aerospace, automotive, and robotics). 

Simulink 

Simulation and analysis of multidomain 
dynamic systems 

Archimate 

Business 

SysML 

Systems of systems 







Modeling Language Attributes 



Formality 


More formality = 
less ambiguity, 
more accuracy 


Abstraction 


Less abstraction 
more detail, 
more precision 
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Abstraction Levels 



Femme au Chapeau Orne 










What is a Formal Model? 



The degree to which the model adheres to: 


• ! Well defined semantics: model 
components have precise 
interpretations. 

• ! Well defined grammar: model 
components can only be related using 
precise structural rules. 





SysML Semantics 



DEA Tool Functional Use Cases 
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SysML Requirements Relationships 


SysML Requirements Dependency Relationships 
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Any behavioral 
diagram. 
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SysML Diagram Taxonomy 





Nsw diagram ryoe 


Source: OMG Specification 




Applying EA & Modeling to PM 





Modeling and PM 


□i Projects are now modeled using spreadsheets, 
diagrams and documents to represent different parts 
(components) of the project. 

□i A formal model does not change this. Instead, your 
project components must now be represented using 
formal grammar and semantics. And, if you are using a 
standardized framework, your project follows a well 
known architecture. 




System Engineering and Project 
Management 
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From NASA System Engineering Handbook - NASA/SP-2007-6105 




Review Entrance Criteria 

(NASA Systems Engineering Handbook) 


Milestone 

Artifacts 

System Concept Review 

System Goals And Objectives 


Concept of Operations 

System Requirements Review 

System Requirements 


System Functionality Description 


Concept of Operations 

Preliminary System Requirements 

Preliminary Design Review 

Preliminary subsystem design Specs 

Operational Concept 


Interface Control Documents 


Requirements Traceability Matrix 


These can all be described in one model! 









28 


Building ConOps from Model 


Conops Section 

DoDAF product 

SYSML Model 

Scenarios 

OV-5 Activity Diagram 

Use Case Diagram, Activity 
Diagram 

Conceptual Overview 

OV-1 High Level Concept 

Block Definition Diagram 

Event sequence 

OV-6c 

Sequence Diagram 

Connectivity 

Architecture 

OV-2 Node Connectivity 
Diagram, OV-3 Information 
Exchanges, SV-1 System 
Interface, SV-2 System 
Communication 

Block Definition Diagram 


Glossary 


AV-2 Integrated Dictionary 


Block Definition Diagram 








Technical Decision Analysis 


(Trade Analyses) 
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bdd [Package] AflditionlnstanceOI [ InstancoOl |J 


Instance 


bdd (Package] Addition 1 AodrtonaDD jJ 


Structural 






« Wock» 

qammaOl ; Gamma 
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bet - betaOl 
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Functional 





Formal Modeling and Six Sigma 

(Complementary Technologies.) 



Formal Data No Yes Yes 

Semantics & Grammar 

Data Persistence No Yes Yes 








Case Studies 





MOD Flight Production Process Re- 
en gineerin g 

□! Goal: MOD needs to transform into an agile organization to be able to quickly meet 
needs and opportunities that arise in the next decade. 

□! Challenge: Currently, most information about how we conduct business is housed 
in different documents, spreadsheets, systems and other repositories. It is difficult 
to gain a comprehensive, integrated, common view of the way we conduct 
business and what the impact of changes are on our people, processes and 
systems. 

□! Approach: An enterprise architecture provides a framework that will allow us to 
organize information about our people, processes and systems in an organized, 
structured and integrated manner. 

□! Benefits: An organization that can quickly assess the impact of external events 
saving $$$$ and reducing risk. 



MOD EA Repository 
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0.2, 1.3 Sl_l - Generate Dav-of-launch 1-Load Update 
Instance - Step 1 

-> Mi:i'iDe:-i-~.' f'l'J t ‘Jcftwate P'scicpar-.y 
Ret-Ab:’ H.c.'i ■. (PM) 




Performers 


Use Architecture Information for 
Several Purposes 





DoDAF Connectivity Diagram (OV-2) 


OV-2 Operational Nodo Relationship Description [ Eg 4.1.1 OV-2 ) 
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« InformatKxiDement » (J) 

Mission Requirements 
Reloaso 



Flight Readiness System 


□! Goal: Develop a new system to support certification of 
flight readiness for Cx 

□i Challenge: How do we specify the components of our 
system with varying levels of detail while maintaining 
consistency throughout 

□! Approach: Use DoDAF/UPDM to describe the 'as-is' 
process and systems for shuttle. Then design a new set 
of processes and supporting systems for Constellation 
as a 'to-be'. 

□i Benefits: Information is organized and represented 
consistently with various levels of detail appropriate to 
different stakeholders 



As-ls and To-Be Templates 



As-ls 


To-Be 
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&-T“| All Views 
:-r i Operational View 

| OV-1 High Level Operational Concept Graphic 
r OV 7 Operational Node Relationship Description 
y Relations 

Dl •!!».'- 1 . 

1 05 1 ■ ■ i 

, COR No.ir • 

MOO • 

MOO $SR OS 01 Division flight Readiness Review •. 
/- J Operational Information Lxchange Matrix 
4 Organizational Relationships 
Relations 
Administrator 
Data Gatherer 
executive 
Manager 

Dl «ACtO ) 2 1 J.ltlOUa 

DS 

flight Rules Engineer Atvu <!»*<• jtt 
COR >'0f i : iT'nri* 

MOR Ar i . i : . 

/-S OpcrationiJ Activity Model 
Relation* 

I Activities 

i MOO SSP Division Flight Read ^ss • r 
MOO 5SR DS f liq*t Readiness « i J 

^-6a 
J- 6b 
i/-6c 

information Model 
Relations 

I Information Llemeots 

I CoFR Responsibility y itr» 

I Hawistinnc * 



B-O-i Cx Model 
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Flight Readiness "As-ls" OV-5 






Flight Readiness "To-Be" OV-5 
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Flight Readiness System Model 





Modeling Ares Development 


Problem Definition: 

1. ! Large amount of data... 

2. ! maintained in three separate artifacts: document, 

spreadsheet and diagram... 

3. ! to meet different stakeholder needs. 

Lead to the following concerns: 

1. ! Time consuming and error prone to modify 

data as Ares program changes. 

2. ! Not easy to meet new stakeholder needs. 




Ares Model Architecture 

(UPDM) 


EJ-Cs) Ares Model (by Administtalcri 

6-fj All Views 
B-lJ Operational View 

l+l-Cj OV-1 High Le.el Operational Concept Graphic 
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Ares Document Attributes 
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UPDM 0V7 Diagram 

(Structure) 
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UPDM 0V2 Diagram 


(Behavior) 
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UPDM Exchange Types 
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Ames and EBA 











EBA Architecture 
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Use Cases 






SysML Activity Diagram 
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Inventory Scanning Process 

Obtaining Initial Results 


Diagram name 

Perform Inventory 

Author 
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Creation date 
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Modification date 

10/27/10 222 PM 




Constraints 





< > 

E}-l> Record FOS Item -170 hr* 
ffi-l > Perform Inventory-3170 hr* 

£M } Scan items -3000 hrs :t ii Administrator) 

I— lh 3000 hrs 

GD— ! ) Establish Schedule- 10 hrs 
®-i \ Obtain Schedule Agreement- 117 hrs 
&-I > Prepare Scanner-50 hrs 
ffi-n Requirements 
GD— r i Stakeholders 

0-T i Use Cases 
i A c^4. 


<7* . i 

COO 


D ■ p 

no<um»nu>i}n 


Oocumcmation of Constraint Scan Items 
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Applying Constraints 
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Making Modeling Work for You 
Todav 


Practical Information for achieving quick ROI 



Modeling is an Engineering Task 


□(Approach it systematically 
□i Know what resources you will need 
□i Define milestones, a roadmap 
□i Be pragmatic 




What Makes a Good Formal Model? 


□i Model those aspects of the project required to 
answer stakeholder questions, and no more. 

□i Model the degree of precision required to answer 
stakeholder questions, and no more. 


□i Models must always be accurate. 




Five Knowledge Domains 

(Why modeling is hard) 


Need to know 
Architectural 
Framework 


Need to 
understand 
stakeholder 
questions 




Need to 
understand 
modeling 
semantics 
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Need to know 
modeling tool 











Four Modeling Steps 


(Do only one at a time.) 



translate to 


Architectural Framework Knowledge 


apply to 


Modeling Language knowledge 


apply 


Tool knowledge 











Modeling Tools Encompass Two Areas 

(Do only one at a time.) 


□i Database program 
□i Drawing program 




Think Small, Think Focused 

(Get ROI in Weeks!) 

□i What questions should your model answer? 
□i Select a modeling language. 

□i Determine the architecture. 

□i Select a tool. 




You're in Front of your Computer 

(Now what do you do?) 

□! Your tool is running 

□i You created a new SysML project 

□! And... 

□i You create packages to organize your project 


Uodrl Mime 
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—CD W** C 




A "Template" SysML Model 
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— O Build Capsule 
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Extending SysML 


□i Use English to document each entity. 

□! Use diagram notes to highlight explain diagram 
elements. 

□! Use SysML Profiles to extend SysML semantics to 
meet your own domain specific needs. 




Modeling Tips 


□i What if you don't know something? 

□ Make your best guess, its easy to change. 

□i What should go on a diagram? 

□;lt should tell a story, answer a question, address a 
specific stakeholder need. 

□i Look to see how a set of diagrams might meet a 
stakeholder's need in some specific area. 

□i Model only those elements for which you know 
there is a value. 




Culture Issues 

(Modeling is about sharing information.) 

□! Some people do not necessarily want to share 
their information 

□ Job security 

□ They don't know the information, and perhaps 
reluctant to say so. 

□ Its time-consuming to get the information, what's in it 
for them? 

□i Some people like to work independently 




Modeling Summary 


□iThink small, know what questions your model 
should answer. 

□i Keep the architecture simple. 

□! Learn your modeling language semantics. 

□i Pro actively manage the modeling task: 

□ Engineering effort 

□ Cultural issues 




Future Trends and Closing Remarks 





Future Trends 


□i Fully defined semantics 
□i Prescriptive methodologies 
□! Improved tooling 
□! Analytical integration 

□! EA Frameworks are adding behavior and project 
management representations 




Backup 


70 




71 


DODAF 2.0 


Capability Viewpoint 


Vision 
Taxonomy 
Phasing 
Dependencies 
Organizational Mapping 
Activities Mapping 
Services Mapping 



Project Viewpoint 




Portfolio 
Timelines 
Capabilities Mapping 





Project Management Information: 

Gantt Chart, Event Chain Diagram, ISO 10006, Six Sigma 


...producing strategic 
PM artifacts... 


...leading to better estimates for 
schedule, scope and resources.. 



.and also used for aligning project 
schedule, scope and resources... 


O 


...maintaining a consistent, feasible 
project and a refined model... 


Formal Model Formal semantic relationships + consistent representations 
|E3 improved common understandings & decisions. 


© 


.used for creating 
SysML model... 



...providing consistent operational 
information used by all stakeholders. 


.which encompasses 
project data... 


Text Docs I Spreadsheets 


Diagrams 


v_ 


^ Represented by... 


T 



Projects are defined and change mostly due to external events: Continuously. 









